The executeMonitorHeld method for ExecutableWork lacks error handling for task submission and execution failures, which can lead to resource leaks in elementsOutstanding and bytesOutstanding.

1. If executor.execute() throws a RejectedExecutionException (e.g., during worker shutdown), the counters incremented just before will never be decremented, leading to a permanent capacity leak in the JVM.
2. If work.run() throws an exception and the JVM does not immediately terminate (e.g., if the exception is caught by the thread pool's uncaught exception handler but the process continues), the counters will also leak.

This implementation should be made consistent with the Runnable version of executeMonitorHeld (lines 248-272), which correctly handles these scenarios. Even if a JVM crash is expected on work failure, providing a defensive decrement (using the initial workBytes as a fallback) is safer.

    try {
      executor.execute(
          () -> {
            WorkResult result = null;
            try {
              result = work.run();
            } finally {
              // Any execution exception thrown by work.run() propagates uncaught, triggering
              // the default JVM UncaughtExceptionHandler which immediately crashes/terminates
              // the JVM. Since the process exits immediately, reclaiming resource budgets in
              // this JVM is unnecessary. Furthermore, since a failed execution does not return
              // a WorkResult, we fallback to decrementing the initial budget to prevent
              // resource leaks in case the JVM does not crash.
              decrementCounters(result != null ? result : WorkResult.create(1, workBytes));
            }
          });
    } catch (Throwable e) {
      // If the execute() call threw an exception, decrement counters here.
      decrementCounters(WorkResult.create(1, workBytes));
      throw ExceptionUtils.propagate(e);
    }

The pollWork method executes any non-QueuedWork items (such as callbacks submitted via forceExecute(Runnable)) directly on the calling thread to "drain the queue" while searching for the next QueuedWork. This is a significant change in behavior, as these tasks were previously always executed by the executor's thread pool. If these callbacks are long-running or perform blocking operations, they could delay the completion of the current work item and the release of its associated budget. While this is necessary to reach items further back in the LinkedBlockingQueue, it should be monitored for potential impact on worker thread latency.

The getter is unused now. Planning to improve the logic before using it. This change is just setting up the Handles and getters.